I believe it is now time to close the first part of my series on data management and to stop talking about Excel. For some readers, this article may be five or ten years late. For others, it will be entirely current. My intention was to start where many teams actually are. And while I rarely use Excel to store data nowadays, I wanted to begin with the reality most Compliance and Legal teams face.

This article explains why Excel is not a long-term data governance solution, and why you should consider moving away from it if you still rely on it.

There is a theoretical answer to this: Excel does not natively enforce relational modelling principles such as normalisation, referential integrity, transactional consistency, and structural constraints that are fundamental to reliable database systems.

Obviously, this is not how I am going to convince you to stop using it. Instead, let me give you five practical pain points that will very likely sound familiar.

Multi-Value Fields

In the templates I shared previously (for example, the Conflict of Interest register and the Contract register), I deliberately designed some of the fields as singular:

• One conflict involves ONE legal entity
• One contract involves ONE counterparty

But reality is rarely this simple. Conflicts may involve multiple legal entities. And contracts often have several counterparties. So it appears in this case that the Excel register is too restricted and you would be right to think so.

But a question arises: How would you link several legal entities to one conflict in Excel? This is where Excel fails to provide an acceptable native solution. It simply does not manage multi-value fields well, but this is a very common need. There is probably at least one multi-value field in every register / log you create.

This is a significant limitation. Although workarounds exist, they are far from ideal.

One option is to list multiple entities in a single cell, separated by commas. The information remains readable, but it is no longer properly structured. Filtering, counting, or analysing conflicts by legal entity becomes unreliable because the cell has effectively turned into free text.

Another approach is to duplicate the row — creating one row per entity. However, this introduces unnecessary repetition. If the mitigation details change, each duplicated row must then be updated individually.

For me, this limitation alone is enough to justify moving away from Excel.

Repeated data and no automatic links between records

If you use Excel, you probably have the feeling that you are typing the same information in multiple places or across different registers. It may even seem normal to you. But it is not best practice at all.

Without going too deeply into database theory, there is a fundamental philosophy which basically states that a piece of information should be stored only once, in a single location. If the same data has to be entered in multiple places, it usually means the database is poorly designed.

Let’s take a simple example. Imagine you maintain a register of legal entities (Company 1, Company 2, etc.) and a separate register of conflicts of interest, where each conflict is linked to one legal entity. Now imagine that the name of one of those legal entities changes. What needs to be updated? You must update the Legal Entity register. But that is not enough. You must also update every entry in the Conflicts of Interest register where that company appears. Every single one.

This example is simple, but the situation is extremely common when working with Excel. And to be clear, this is not strictly an Excel problem. It is a data design problem. It simply happens more often in Excel because spreadsheets are typically built without enforcing proper data structure.

The illusion of data validation

I have already discussed this point in more detail in "9 Common Excel Mistakes That Undermine Your Compliance and Legal Data" and "How to Use Excel as a Database: A Practical Guide", so I will not repeat everything here. However, the limitations of Excel’s data validation features remain, in my view, one of the main reasons not to rely on it long term.

It is important to understand that without strong validation of data inputs, data quality will inevitably deteriorate over time which will make it increasingly difficult to analyse and use for all sorts of projects.

A common example is dates. Dates can be extremely valuable, particularly when you begin automating reporting processes or looking for trends within your data. However, without proper validation, entries such as "unknown", "n/a" or inconsistent formats (UK versus US) quickly make the dataset unreliable and difficult to use.

Limited Audit Trail and Traceability

Another major limitation of using Excel is the lack of proper auditability. It is extremely difficult to track how a cell’s value has changed over time. I cannot count the number of times I have tried to determine who modified a specific value and when.

This becomes even more problematic when Excel files are shared with colleagues, which is very often the case. While cloud-based versions of Excel make it easier to restore previous versions, this is still insufficient from a governance perspective. But from my point of view, every change should be traceable, attributable to a specific user, and timestamped. Without that level of control, the quality of data becomes significantly reduced and make the effort to understand any change almost mission impossible.

Excel was not meant to be a relational database system

It took me years to fully internalise this distinction: Excel is not and has never been a relational database.

Excel was designed as an electronic spreadsheet, essentially a digital ledger. Its primary purpose is to organise figures, perform calculations, and build models.

At first glance, spreadsheets and databases seem similar. Both store data. But they are built around different priorities. A spreadsheet stores data so it can be manipulated (e.g., to calculate totals, test scenarios, or analyse figures). Storage is a means to an end. The core objective is calculation.

A relational database, by contrast, is designed to manage structured data over time. Its priorities are integrity, controlled relationships between records, traceability, and scalability.

Historically, there was a clear distinction within Microsoft’s software ecosystem. Some of you may remember Microsoft Access, which was designed as the database tool, while Excel was positioned as the spreadsheet application. In practice, I guess that many organisations relied almost exclusively on Excel to store operational data, largely because it was simpler and more accessible. Personally, I have never encountered Microsoft Access being used to manage Compliance or Legal data.

I suggest watching this short video on the ancestor of Excel.

Conclusion

We live in a time where data is an asset for you and for your organisation. Assets should be treated accordingly. You would not build your headquarters on mud. In the same way, your data deserves better than a spreadsheet stretched beyond its limits. For that reason, I hope I have convinced you that you should stop using Excel to store your Compliance and Legal data. I will probably stop talking about Excel (and I am quite happy about it), unless specifically asked to. It has served its purpose in this series. Now it is time to move on.

To end on a balanced note, Excel still has a role. It is excellent for prototyping. It works well when building a proof of concept, testing a structure, or demonstrating an idea quickly before transitioning to a more robust solution.

In the next articles, we will look at what data management really means once you move beyond Excel.